-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test that postMessage doesn't block on event loop #23270
Test that postMessage doesn't block on event loop #23270
Conversation
cc @annevk @surma - I want to convert this to I think that in the current form this is good enough to verify the expected behaviour and will help me as a reference for Chromium bug report. I've also verified that this works as expected on Firefox nightly (which has COOP support by default). |
Per spec postMessage should queue a message up on the target port immediately. Instead, when Workers are involved, some implementations queue a task up on current thread's event loop, which means that in case it gets blocked, some messages are never sent. Resolves whatwg/html#5485.
5391ee9
to
48bdc4f
Compare
It seems like you haven't seen whatwg/html#5476. We should not rely on data URL dedicated workers being able to share memory in this way. Looks good otherwise. Might wanna use more |
Yeah definitely didn't see it, just searched the codebase for Workers, noticed that others also used data-URI and assumed it's fine. I can convert, but not sure where to put the worker JS. My understanding is that I can't name it as |
Could just create a blob URL |
Ah yeah I suppose I could. For now already updated to use a separate file, but open to changing it to something else if preferable. |
97dcf72
to
8a2fd69
Compare
When the test
is run at Nightly 77 at
run at plnkr.co and
|
Can a version be made without |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me, but please put the helper file in a resources/
directory.
@guest271314 As the error says, you need to have corresponding headers set for SAB to work. They're set in these tests correctly, but won't be on 3rd-party resource. I don't think version without SAB is possible, because it's the only Web API that provides synchronous communication channel that doesn't rely on the event loop, and making sure that we don't wait for an event loop spin is the primary point of this test. |
@guest271314 If you really need to run this test on a different hosting / protocol, you can enable shared memory on any pages without COOP/COEP via |
@annevk The Should I still create a new |
Moved to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @RReverser! I take it this passes in Firefox and fails in Chrome? Please list the Chrome bug here in a comment in case someone needs it while going through blame.
@annevk Thanks for the review! The relevant Chromium bug is here: https://bugs.chromium.org/p/chromium/issues/detail?id=1075645 |
Am not entirely sure what the test does and what the expected result is, after reading the HTML issue, where it was mentioned that the test can be composed without using
Is the above statement not true and correct? That using Does the same issue occur when transferring a For context, when initially read the title of the PR had the impression that the issues that had encountered transferring 500,000 |
@RReverser It could probably be argued that the gaps in silence when using plnkr to observe the output and compare for yourself using |
What I mentioned there is that issue can be observed in Chrome even without SAB, but e.g. console.log won't work in Firefox. In the end, SAB is the only API that can be used for automation, and it was the original use-case that revealed this issue. You still haven't explained why you want to use a 3rd-party hosting for this WPT test and whether the provided workaround works for you, so I'm not sure how to help further at this point.
Sorry if I misunderstand, but it seems like you're describing completely different issue - a performance overhead from sending large amount of messages in Chromium? If so, it's not related to this test in any way which checks for a cross-browser spec compliance in regards to sending a single message. If you have a well-defined repro and believe this is a bug, you might want to submit an issue on the Chromium repo instead. |
Consider WebAudio/web-audio-api-v2#73 (comment)
In particular, if Both inferred or implied recognition that using |
Perform all WPT tests by hand, locally, here. No automation. Already filed Firefox and Chromium bugs - and for the case of Disable cache further impacting whatever code is ongoing. Again, the title of the test implies full coverage of various cases where If that is the case What is the difference between transferring a In any event, at least this is a start in the same or similar domain. |
Sorry, I'm not familiar with Web Audio API, and, as I said above, I think it's best you raise a separate issue (or a PR if you have something specific in mind), so that people familiar with it could review. This PR has been already closed and might be not the best place for such discussions. |
That's probably the only part I can respond to - if you haven't seen yet, there is a doc section on running WPT tests locally: https://web-platform-tests.org/running-tests/from-local-system.html You can't just extract the code from the test to a different server without replicating corresponding configuration, as it won't behave in the same way (as you've seen for yourself). |
What happens when the automation testing code has a bug? Then there are two code bases being tested. Prefer to just extract the relevant code and run locally. Am not sure how the tests at #22779 are passing where when ran locally Have other experiments and proposals that am considering re extending Again, your PR at least breaches the topic. |
Per spec postMessage should queue a message up on the target port immediately.
Instead, when Workers are involved, some implementations queue a task up on current thread's event loop, which means that in case it gets blocked, some messages are never sent.
Resolves whatwg/html#5485.